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DIGITAL RIGHTS MANAGEMENT SYSTEM FOR MULTIMEDIA MESSAGES 

PROTECTION AND TRACKING 

FIELD OF THE INVENTION 

The present invention relates to content protection for multimedia content. 

BACKGROUND OF THE INVENTION 

Background technologies relevant to understanding the present invention include: 

- Simple Object Access Protocol (SOAP), which is described on the World Wide 
Web at: www.w3.org/2000/xp/Group/ 

- SOAP Security Extensions: Digital Signature (SOAP DSIG), which is described 
on the World Wide Web at: www.w3.org/TR/SOAP-dsig/ 

The disclosures of all references mentioned above and throughout the 
present specification (including, without limitation, references mentioned in Appendix 
A), as well as the disclosures of all references mentioned in those references, are hereby 
incorporated herein by reference. 



Copy provided by USPTO from the IFW Image Database on 02/11/2005 



SUMMARY OF THE INVENTION 



The present invention, in preferred embodiments thereof, provides a system and method 
for content protection for multimedia content distributed in a mobile network by 
Multimedia Message Service Center (MMSC). In preferred embodiments, the system 
includes a Digital Rights Management (DRM) server connected to the MMSC by a 
dedicated DRM protocol or by connection via selected MMSC protocols. The system 
may also include a DRM User Agent (UA) on mobile handsets. 
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BRIEF DESCRIPTION OF THE DRAWINGS AND APPENDIX 

The present invention will be understood and appreciated more fully from the 
following detailed description, taken in conjunction with the drawings in which: 

Fig. 1 is a simplified block diagram illustration of a 3GPP MMSC System having 
an MM9 interface; 

Fig. 2 is a simplified block diagram illustration of a Multimedia Message Service 
Center (MMSC) including a Digital Rights Management (DRM) server, constructed and 
operative in accordance with a preferred embodiment of the present invention; and 

Fig. 3 is a simplified block diagram illustration of a Multimedia Message Service 
Center (MMSC) including a Digital Rights Management (DRM) server, constructed and 
operative in accordance with another preferred embodiment of the present invention. 

The following appendix will aid in understanding the detailed description: 
Appendix A, which is a particularly detailed description of one preferred 
implementation of an interface between a service provider and a DRM Server. 
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DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

Reference is now made to Fig. 1, which is a 3 GPP MMSC System diagram with an 
additional MM9 interface. Fig. 1 is based on the standard MMSC architecture as it is 
defined by 3GPP in reference [11 (a copy of which may be found on the World Wide 
Web at: webapp.etsi.org/action%5CPU/20040120/ts_123140v050900p.pdf) with the 
addition of a transcoder node connected by MM9 protocol. 

It is appreciated that MM9 is not standardized yet and its implementation may be 
proprietary for each MMSC and transcoder vendor. 

The DRM System for Multimedia Message (MM) protection preferably comprises, at the 

server side, one of the following: 

I) 

A DRM component, integrated within the MMSC through a dedicated protocol, 
similar to the current approach to MMSC - transcoder interconnection, as shown in Fig. 
2. The dedicated protocol could be very similar to that described in Appendix A, with 
additional support for extended business models if desired. (It is appreciated that 
Appendix A comprises a particularly detailed description of one preferred 
implementation of an interface between a service provider and a DRM Server; the 
example of Appendix A is not meant to be limiting). 

II) Stand-alone server(s) acting like a network probe and/or proxy, as shown in 

Fig. 3. 

The system of Fig. 3 preferably protects / tracks content following the steps below. The 
DRM Server preferably: 

1 . Listens to MM7 protocol analyzing MM7_submitREQ messages. 

2. For each message, extracts from the message Value Added Service Provider 
(VASP) ID and Value Added Service (VAS) ID and compares them with a pre- 
defined list of the content vendors IDs that request content protection/tracking. If 
the content protection/tracking was required, then: 

3. Generates hash data which uniquely identifies MM content and stores this data in 
the DRM DB together with other data about the message, such as, for example 
VASP & VAS IDs, message recipients) address(es)/distribution list(s), 
submission timestamp, subject, service code, message class, message distribution 
indicator and other appropriate parameters. Data hash technology is well-known 
in the art; any appropriate data hash technology may be used. 

4. Optionally, analyzes content and replaces it by the same content with a 
watermark. This could be used with or instead the content hashing as described in 
step 3 immediately above 

5. Analyzes every message transferred via proprietary MMSC-transcoder protocol 
(MM9). For messages, passed from MMSC to the transcoder, the DRM Server 
generates content hash and/or looks for content watermark. The generated hash is 

4 
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compared with the stored hashes (or the found watermark compared with DB 
stored watermarks). If the same hash/watermark is found in the DRM DB, the 
incoming (to transcoder) message is marked as "to be protected/tracked" by 
storing incoming message parameters such as transaction ID, message ID or 
similar. Persons skilled in the art will appreciate that specific implementation 
details depend on the MMSC-transcoder protocol details, which differs for 
various vendors. 

6. Verifies the same parameters (transaction ID, message ID or similar) for any 
outgoing (from transcoder) message while listening to MM9 protocol. If the 
message should be protected, the DRM Server encrypts content, fully or partially. 
Every attachment can be protected individually by using different algorithms 
and/or keys or all the attachments can be encrypted together with the single key. 
Any appropriate encryption algorithms and key management and key delivery 
mechanisms may be used. 

7. Generates an additional post-transcoding hash data for the transcoded content and 
stores this data in the DRM DB. 

Then the message is delivered by MMSC, preferably using standard methods known 
in the art, to the recipient MMS UA. 

In order to implement the protection for the super distribution (i.e. forwarding all the 
content items received within the MM or selected content items only from one mobile 
subscriber to the another one) in case of Multimedia Message (MM) submitting (which 
may occur when only selected attachments of received MM are forwarded) and MM 
forwarding (entire MM), the DRM server preferably: 

1 . Listens to MM1 protocol and analyzes every MMljsubmitREQ message by 
generating a content hash. The hash is compared to the "post-transcoding" hashes 
in the DRM DB. If the generated hash matches a hash in the DB: 

2. Registers message parameters such as originator, recipients list, timestamp and 
others as appropriate. 

3. Verifies the rights of the recipients) to receive the message. If the recipients) is 
not allowed to receive the message, e.g. the MM was requested to be forward- 
locked by the content or service provider, the DRM Server may: 

a. Silently ignore the MM forward attempt. 

b. Inform the MM originator that the delivery is not allowed, by SMS, MMS, 
WAP push or other allowed methods. 

c. Inform MM recipient that there was a MM forwarding attempt. 

If the message delivery to the receipient(s) is allowed, optionally the DRM Sever 
may request the recipient to purchase the appropriated rights for the forwarded 
content first and execute all the steps below only when the purchase confirmation 
will be received. If the DRM Server is allowed to deliver the message: 

4. Decrypts content and replace the encrypted attachments by clear content inside 
the MMljsubmit.REQ message. Then the message is delivered to the MMSC 
Server/Relay which in turn may pass it to the transcoder. Further operations are 
defined in steps (5)-(7) for MM9 above. 
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5. In addition, listens to MM1 protocol and analyzes every MMljretrievcREQ and 
MMl^retrieve.REQ messages, extracting message reference, typically in the form 
of a Universal Resource Identifier (URI), which URIs are well-known in the art, 
from MMl_retrieve.REQ and storing the message reference in the DRM DB if 
content hash generated by the DRM Server for content passed in 
MMl_retrieve.RES matches with a hash stored in the DRM DB. 

6. Listens to MM1 Jbrward.REQ, extracting message URI and comparing with the 
stored URIs. For the matching URIs, registers in the DRM DB the recipient's 
address and originator address presented in MM 1 Jbrward.REQ message. 

Additionally, persons skilled in the art will appreciate that the DRM server preferably, in 
both cases (I and II), provides portal functionality for the DRM UA to supply keys as 
necessary, both on DRM UA request or provided by DRM Server by an appropriate push 
method such as SMS, WAP push or MMS. 

At the handset side the DRM User Agent (UA) implementation can be one of the 
following: 

1) No DRM U A 

In this case the DRM Server alone preferably supports the following business 
models: content tracking, network forward lock (with/without notification of the 
originator), controlled super distribution. 

2) DRM UA built-in the MMS UA. 

3) DRM UA acting as a stand-alone application / group of applications (such as, 
for example, a Symbian recognizer [which is well-known in the art and 
described on the World Wide Web at: 

www.symbianxom/developer/techlib/v70sdocs/doc_source/devguides/cpp/ap 
plicationframework/recognizersoverview.guide.html ] + UA) or as a part of a 
third-party stand-alone application (DRM UA for a player or browser), when 
the application is associated with the protected content types (and called by 
the Operating System (OS) when a MMS with protected content is received) 

4) DRM UA acting as a part of the native phone software (OS, drivers etc) 
(including any HW implementation) - in the most common case is the same as 
(1); other options: part of a web/WAP browser. . 

For cases (2)-(4) DRM Server and DRM UA will support any appropriate 
business model implemented in the given DRM System, e.g. pay-per-count, pay- 
per-time, rental or permanent purchase. 



R.efier enc e * 

[1] ETSI TS 123 140 V5.9.0 (2003-12) 

Digital cellular telecommunications system (Phase 2+); 

Universal Mobile Telecommunication System (UMTS); 

Multimedia Messaging Service (MMS); 

Functional description; 

Stage 2 
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(3GPP TS 23.140 version 5.9.0 Release 5) 

It is appreciated that various features of the invention which are, for clarity, described 
in the contexts of separate embodiments may also be provided in combination in a 
single embodiment. Conversely, various features of the invention which are, for 
brevity, described in the context of a single embodiment may also be provided 
separately or in any suitable subcombination. 

It will be appreciated by persons skilled in the art that the present invention is not 
limited by what has been particularly shown and described hereinabove. Rather the 
scope of the invention is defined only by the claims which follow: 
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What is claimed is: 



CLAIMS 

1 . Apparatus substantially as described hereinabove. 

2. Apparatus substantially as shown in the drawings, 

3. A method substantially as described hereinabove, 

4. A method substantially as shown in the drawings. 

5. A system substantially as described hereinabove. 

6. A system substantially as shown in the drawings. 
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FIG. 2 
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FIG. 3 
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1 . Scope 

This document describes the interface between the Service Provider (SP) and NDS 
Digital Rights Management (DRM) server. 



2 Related Documents 



Doc. Designation 


Document Title 


[1]OMA-Download 


OMA DCF file format 


DRMCF-v1_0- 


20031 113-C: 




[2] OMA-Download- 


OMA DRM 


DRM-V1_0- 




20031 03 1-C: 




[3] OMA-Download- 


OMA DRM Rights expression language 


DRMREL-V1_0- 




2003 103 1-C 





The OMA reference documents listed above can be found at the following URL: 
htt p://www.openmobilealliance.org/release prograni/enabler releases.html 
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3 Overview 

This interface defines communication between the service provider and NDS DRM 
server. The main functions of the interface are: 

• Protecting content 

• Generating a Rights Object (RO) to regulate content rendering by a Mobile 
Subscriber (mobile subscriber) 

The interface supports all types of content protection (Forward Lock, Combine 
Delivery, Separate Delivery) and full functionality of ROs defined in [3]. RO 
functionalities are triggered by a mobile subscriber request to a service provider. The 
structure of the mobile subscriber request is outside the scope of this specification. 

Additional functionalities required for the DRM server but not included in the 
interface definition below are: 

• Service provider registration/authentication 

• Mobile subscriber registration/authentication 

The SP registration is triggered by the Management Station (MGMS). The MGMS 
shell registers each SP and SP service in the DRM server. The SP registration 
protocol, as well as SP authentication, is outside the scope of this specification. 

Mobile subscriber authentication is performed by the SP upon a mobile subscriber's 
request for content. The registration/authentication can include the mobile subscriber 
identity, e.g., MSISDN, XID, cookies as well as the handset type (e.g. Nokia 6220) 
used by mobile subscriber. 
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3.1 DRM System Component Interaction 

Figure 1 below describes how the DRM system components interact. 
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Figure 1: Overview. DRM System Component Interaction 
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3.2 DRM Server's Role 

In the scope of this document, the DRM server protects content and generates the RO 
for the content consumption by the mobile subscriber. The DRM server role is to 
optimally protect content for each mobile subscriber's handset, providing each 
handset with the best security level it can accept. 

For example: if a specific handset supports the Forward Lock protection method 
only, the content for this handset should be Forward Lock-protected. If another 
handset supports both Forward Lock and Separate Delivery protection methods, the 
content for this handset should be protected by the Separate Delivery method and an 
appropriate RO should be generated and delivered to the handset as defined in 
specifications [2], [3]. 

The content protection method is chosen by the DRM server according to the 
content's handset type and MIME type. Choosing a content protection method is 
transparent to the SP. 



Interface Principles 



The interface described in this document uses Simple Object Access Protocol (SOAP) 
for the messages exchange. 



1 Service Provider Authentication 

SP authentication is performed by the DRM server during the communication 
session with the SP. The authentication details are outside the scope of this 
document. 



2 Mobile Subscriber Registration/Authentication 

Mobile subscriber authentication (both Mobile Subscriber ID and Mobile Subscriber 
type) is performed by the SP. The SP is responsible for transferring the Mobile 
Subscriber ID and handset type to the DRM server. 



3 Permissions Handling 

The SP must provide the DRM server with all information needed for content 
protection and RO generation. One of the parameters necessary for RO generation is 
permission as defined in [3]. Permissions are the part of the business scenario 
associated with the content, e.g., how often can content be viewed. The business 
scenario defines how content can be bought by the mobile subscriber.. The sequence 
for implementing permissions for a mobile subscriber is as follows: 

1 . The mobile subscriber selects the content. 

2. The mobile subscriber purchases rights for the content. 

3. The SP sends the permissions associated with these rights and the handset model 
name to the DRM server. 

4. The DRM server checks the handset type to determine whether permissions can 
be implemented. 

For example, if the handset supports only Forward Lock protection (Nokia 6600), 
then permissions such as "play 5 times" cannot be implemented. If the handset is 
able to implement all permissions, the content will be optimally protected by the 
handset and an RO will be generated if needed. If the handset is not able to 
implement certain permissions, the DRM server will implement the best content 
protection available. Notification, with an error code, will be sent to the SP. 
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Optionally, an SP can request from the DRM server a list of permissions that the 
particular handset type can implement for a particular asset type. This information 
can be used by the SP to display to the mobile subscriber only the permissions that 
the handset can implement. 

4^T" Security Considerations 

The SOAP digital signature (SOAP DSIG) can be used to secure communication 
between the SP and the DRM server. 



4.5 



Interface Structure 

The interface structure supports SOAP communication, where each transaction 
consists of request and response XML messages transferred over HTTP. 

1 . Protect content request 

a. RT-ProtectContent-reqRequest 

b. ProtectContentResponse 

2. RO request 

a. RO-reqRequest 

b. RO-Response 

3. DRM permission request 

a. DRM-permission-reqRequest 

b. DRM-permission-Response 



XML Parameter Description 

Table 1 below describes the interface parameters. 



Table 1 : Parameter Description 



Parameter Name 


Description 


v ersmjii 


This, narametpr defines the interface version 


<sr\/TH 
OI VI tl 


This narameter uniauelv identifies the service in 




the DRM server. 


xjli icxi y ivw 


RO in WBXML format. 


cid 


Unique identifier generated by DRM server per 




each content encryption. Is defined in the DCF 




Viparlpr fl 1 


MobSubsId 


Mobile subscriber ID. This complex parameter 




uniquely identifies the subscriber in the network. 


MobSubsIdType 


Sub-parameter of MobSubsId. This parameter 




defines which type of identification is used by 




the SP. 


MobSubsIdValue 


Sub-parameter of MobSubsId. This parameter 




defines the ID value used, according to the 




chosen type. 


MS_model 


Mobile subscriber handset model 


TsourceContent 


This complex parameter incorporates all source 




(clear) content parameters used by the DRM 




server to protect content. 


SourceContentID 


Sub-parameter of tSourceContent. Unique ID of 




the clear content per SP This parameter is 




managed by SP and provided to DRM server as 




part of the RtProtectContentReq request. 


ContentName 


Sub-parameter of tSourceContent. This 




parameter is used in the DCF header, see [1]. 
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Parameter Name 


Description 


ContentDescription 


Sub-parameter of tSourceContent. The parameter 




is optional. This parameter is used in the DCF 




header, see [1]. 


MIMEjype 


Sub-parameter of tSourceContent. This 




parameter defines the MIME type of clear 




content. 



EncodingType Sub-parameter of tSourceContent. The parameter 

is optional. When SP issues an RO request for 
super distribution of the content, the DRM server 
compares this parameter with the EncodingType 
parameter of the mobile subscriber. In case of 
encoding type incompatibility, notification will 

be sent to SP. 

ContentProviderWeb Sub-parameter of tSourceContent. The parameter 

is optional. This parameter is used in the DCF 
header see [1]. The default value of the 
parameter is configured in the DRM server 
configuration. The value from configuration is 
used if the parameter is absent from the 
RtProtectContentReq request. 

Content Vendor Sub-parameter of tSourceContent. The parameter 

is optional. This parameter is used in the DCF 
header see [1]. The default value of the 
parameter is configured in the DRM server 
configuration. The value from configuration is 
used if the parameter is absent in the 
RtProtectContentReq request. 

SourceContentLocation Sub-parameter of tSourceContent. The parameter 

is optional. This parameter defines the source 
content location. If the parameter is absent, the 
source (clear) content should be sent in the same 
HTTP stream as the RtProtectContentReq 
request. 
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Parameter Name 



Description 



SourceLocation 



Sub-parameter of SourceContentLocation. This 
parameter defines the URL of the source content 
location. 



SourceDownloadProtocol 



Sub-parameter of SourceContentLocation. The 
parameter is optional. This parameter defines the 
protocol of the source content download (HTTP, 
FTP, file system). 



SourceDownloadProxy 



Sub-parameter of SourceContentLocation. The 
parameter is optional. The proxy is used for the 
source content download. 



ProtectContentLocation 



Sub-parameter of tSourceContent. The parameter 
is optional. This parameter defines protected 
content location. If this parameter is absent, the 
protected content should be sent in the same 
HTTP stream as the RtProtectContentReqResp 
message. 



Provocation 



Sub-parameter of ProtectContentLocation. This 
parameter defines the URL of the protected 
content location. 



ProtUploadProtocol 



Sub-parameter of ProtectContentLocation. The 
parameter is optional. This parameter defines the 
protocol of the protected content upload (HTTP, 
FTP, file system). 



ProtUploadProxy 



Sub-parameter of SourceContentLocation. The 
parameter is optional. The proxy is used for the 
protected content upload. 



tAssetRights 



Complex type, defines asset consumption rights. 



Price 



Sub-parameter of tAssetRights. Defines the price 
of the asset. The price is used for statistical 
purposes only. 
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Parameter Name 


Description 


Currency 


Sub-parameter of Price. The parameter is 




optional. This parameter defines the currency is 




used for the price. The default value of the 




parameter is configured in the DRM server 




rnnfi eviration ner SP The value from 




configuration is used if the parameter is absent. 


Prirp-valtif* 


Sub-parameter of Price. The value that, along 




with n irrpnrv ronnorisps the* oricG 




Sub-parameter of tAssetRights. The parameter is 




nntinnal Permissions as defined in OMA1 (see 




r2i). 


JrJLIiag 


Si lh-narameter of tAssetRiehts Forward Lock 




flag. The parameter is optional. If the parameter 




is present, the content must be protected as 




Separate Delivery with Forward Lock (see [2]). 


tmsRights 


Complex type defines the rights which can be 




implemented by the mobile subscriber for the 




snf»Hfir MIMK tvnp 


Jl erinission 


Suh-narampter of tmsRicfhts Permissions as 




defined in OMA1 (see [2]). 


Jf JLElag 


Siih-narampter of tmobile subscriberRiehts. 


Forward Lock flag. The parameter is optional. If 




the parameter present this means that the mobile 




subscriber of particular type supports Separate 




Delivery with Forward Lock protection type see 




F21). 


"DRMstatus 


Complex parameter. Defines the status of 




request execution. 


ErrorCode 


Sub-parameter of DRMstatus. 


ErrorDescr 


Sub-parameter of DRMstatus. This parameter is 




used to describe the error code. The parameter is 




optional. 



7 Interface Messages 



7.1 Content Protection Transaction 

The request message and response message are defined in the upcoming sections. 
7.1.1 RT Protect Content Request Message 

7,1-1.1 Message definition 

<message name="RtProtectContentReqRequest"> 
<part name="Version" type="xsd:string7> 
<part name="srvld" type="xsd:string7> 
<part name="Source" type="nmdrm:tSourceContent7> 
<part name="MobSubsId n type="nmdrm:tMobSubsId7> 
<part name="mobile subscribermodel" type="xsd:string7> 
<part name="AssetRights" type= ,, nmdrm:tAssetRights7> 
</message> 



13 



7.1.1.2 Types used 



complexType tSourceContent 



diagram 




— 1 = SourceContentID j 
— 1 = ContentName || 
— |~WaimeType j 
--I'EncodingType | 


(tSourceContent^— (^^^p— 


■--j ContentProuiderWeb ?] 




■ - -j 55 Content Vendorjj 

Content Description | 
i-— I SourceContentLocation [+3 
! ProtectContentLocation EH 


namespace 


htto://vvww.ndsxom/NDSDRMS/vl.O/nmdrm.xsd 


children 


SourceContentID ContentName RflimeTvoe EncodinaTvoe ContentProviderWeb 


ContentVendor ContentDescriotion SourceContentLocation ProtectContentLocation 




used by 


element 

tSourceContent 


source 


<xsd:comp)exType name="tSourceContent"> 
<xsd:sequence> 
<xsd:element name^'SourceContentlD" type="xsd:long7> 
<xsd:element name^'ContentName" type="xsd:string7> 
<:xsd:element name^'MimeType" type="xsd:string7> 

<xsd:element name^'EncodingType" type^'xsdrstring" nillable="true M minOccurs="07> 
<xsd:element name= ,, ContentProviderWeb" type="xsd:string" nillable="true" minOccurs="07> 
<xsd:element name= M ContentVendor" type^'xsdistring" nillable="true" minOccurs="07> 
<xsd:element name="ContentDescription" type= ,, xsd:string M nillable="true" minOccurs= M 07> 
<xsd:element name= ,, SourceContentLocation" type= f, nmdrm:tSourceContentLocation" 

nil!able= ,, true" minOccurs^'Cm 

<xsd:element name^ProtectContentLocation" type="nmdnm:tProtectContentLocation" 

niliable="true M minOccurs^O"^ 
</xsd:sequence> 

</xsd:complexType> 
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complexType tSourceContentLocation 



diagram 


i — SourceLocation J 


(tSourceContentLocation [^^-^-^H- - -* = Source Do v^l^a^^rrtoj^^| 


L --i"SourceDownIoadProxy | 


namespace 


http://>AAVw.ndsxon^NDSDRMS/vLO/nmdrrn.xsd 


children 


SourceLocation SourceDownloadProtocol SourceDownloadProxv 


used by 


elements 

tSourceContent/SourceContentLocation tSourceContentLocation 




source 


<xsd:comp!exType name="tSourceContentLocation"> 
<xsd:sequence> 

<xsd:e!ement name="SourceLocation" type="xsd:string7> 

<xsd:element name="SourceDown!oadProtocor type="xsd:string" nillable="true" 
minOccurs="0"/> 

<xsd:element name^'SourceDownloadProxy" type^'xsdistring" nil1able="true" 
minOccurs= M 0"/> 

</xsd:sequence> 
</xsd:complexType> 
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complexType tProtectContentLocation 



diagram 



i — "ProtLocation 



-TPratllploadProtocol | 



namespace 



http://vinvw.ndsxom/NDSDR^ 



children 



Provocation ProtUploadProtocol ProtUploadProxv 



used by 



tSourceContent/ProtectContentLocation tProtectContentLocation 



elements 



source 



<xsd:complexType name= ,, tProtectContentLocation"> 
<xsd:sequence> 
<xsd:element name="ProtLocation n type="xsd:string"/> 

<xsd:element name= n ProtUploadProtocol" type="xsd:string" nillable="true" min0ccurs="07> 
<xsd:element name^'ProtUploadProxy" type="xsd:string" nillable^true" minOccurs^'CT^ 
</xsd:sequence> 

</xsd:complexType> 



complexType tftflobSubsId 



diagram 


i— "RflobSubsldType | 

(tftflobSubsId I^--{~o-]=U — ' " J 

to, im J l—^MobSubsldValue J 


namespace 


http://vvww.ndsxom/NDSDRMS/vl.O/nindrm.xsd 


children 


SVJobSubsldTvoe RflobSubsldValue 


used by 


element 

tftflobSubsId 


source 


<xsd:complexType name="tMobSubsld n > 
<xsd:sequence> 

<xsd:element name^'MobSubsldType" type="xsd:string7> 
<xsd:element name="MobSubsld Value" type="xsd:string7> 
</xsd;sequence> 
</xsd:complexType> 
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complexType tAssetRights 



diagram 


i — Price G}^ 
(tAssetRights l^^~**£^4""; Permi ^^l r § 


namespace 


http://www.ndsxom/NDSDRMS/vl.O/nmdmi.xsd 


children 


Price Permission FLflaq 


used by 


element 

tAssetRiqhts 


source 


<xsd:complexType name="tAssetRights"> 
<xsd:sequence> 

<xsd:element name="Price n type= M nmdrm:tPrice7> 

<xsd:element name="Permission" type^nrndrmitPermission" nillable="true" minOccurs="07> 
<xsd:element name="FLflag" type^'xsdrunsignedByte^nillable^'true" minOccurs="07> 
</xsd:sequence> 
</xsd:comp)exType> 



diagram 


r --j currency 1 
, r ^» m Ji L=p r j ce value 1 


namespace 


http://www.ndsxorn/NDSDRMS/vl.O/nmdrm.xsd 


children 


currency priceValue 


used by 


elements 

tAssetRiahts/Price tPrice 


source 


<xsd:complexType name="tPrice"> 
<xsd:sequence> 

<xsd:element name^'currency" type="xsd:string M nillab!e="true M minOccurs="07> 
<xsd:element name="priceValue" type- , xsd:float7> 
</xsd:sequence> 
</xsd:comp!exType> 
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diagram 


! I 

(^Permission ( "Vfi"! 


play SI 

execute [+| 
print EB 


namespace 


httD://www.nds.com/NDSDRMS/v1 .0/nmdrm.xsd 


children 


Dlav disolav execute print 


used by 


elements 

tAssetRiahts/Permission tHS-Riahts/Permission tPermission 




source 


<xsd:complexType name="tPermission M > 
<xsd:sequence> 

<xsd:e!ement name^'play" type^nmdrmrtPermissionElemenr nillable^'true" minOccurs= , 07> 
<xsd:eiement name="display" type^'nmdrmttPermissionElement" nillable="true" 
minOccurs="07> 

<xsd:element name="execute" type="nmdrm:tPermissionElement" nillable= n true" 
minOccurs="07> 

<xsd:element name="print" type="nmdrm:tPenmissionElemenr nillable^'true" minOccurs="07> 
</xsd:sequence> 
</xsd:complexType> 


nnmnlfixTvne tPermissionElement 


diagram 




(tPermissionElement constraint ^ 


namespace 


httD://www.nds.com/NDSDRMS/v1 .O/nmdrm.xsd 


children 


constraint 


used by. 


elements 

tPermission/disDlav tPermission/execute tPermission/olav tPermission/orint 


tPermissionElement 


source 


<xsd:complexType name-'tPermissionElement^ 

<xsd:sequence> 
<xsd:element name= M constraint" type="nmdrm:constraintType7> 

</xsd:sequence> 
</xsd:complexType> 
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complexType constraintType 



diagram 


r-A~~ count Jj 

i 

(constraintType S— T- 000 -^- ~\"\ datetime |+| 

i 

i 

internal | 


namespace 


httD://www.nds.com/NDSDRMS/v1.0/nmdrm.xsd 


children 


count datetime interval 


used by 


tPermissionElement/constraint constraintTvoe 


elements 








source 


<xsd:complexType name="constraintType"> 
<xsd:sequence> 

<xsd:element name^'count" type="xsd:int" nillab!e= M true" minOccurs=="07> 
<xsd:element name^'datetime" type="nmdrm:tdatatime" minOccurs="0 ,, /> ! 
<xsd:element name= ,, interval" type="xsd:int M nillable="true" minOccurs= ,, 0 , 7> 
</xsd:sequence> 
</xsd:complexType> 



complexType tdatatime 



diagram 


r--{ start 3 
(tdatatime « 
N — J ^— ^ ^-rend | 




namespace 


httD://www.nds.com/NDSDRMS/v1.0/nmdrm.xsd 


children 


start end 


used by 


constraintTvoe/datetime tdatatime 


elements 








source 


<xsd:complexType name="tdatatime u > 
<xsd:sequence> 

<xsd:element name="start" type="xsd:dateTime" nillable^'true" minOccurs="07> 
<xsd:element name^end" type="xsd:dateTime M ^llable^'true'' minOccurs="07> 
</xsd:sequence> 
</xsd:complexType> 
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7.1.1.3 XML example 

<?xml version="1.0" encoding="UTF-8"?> 

<SOAP-ENV:Envelope xmlns:SOAP-ENV== n http://sche^las.xmlsoap,o^g/soap/envelope/' , 

xmlns:SOAP-ENC= ,, http://schemas.xmlsoap.org/soap/encoding/° 

xmlns:xsi="http://www. w3.org/2001/XMLSchema-instance" 

xmlns:xsd= M http://www.w3.org/2001/XMLSchema n 

xmlns:nmdrm="http:/Avvvw^^ 

<SOAP-ENV:Body id=" J>" SOAP- 
E^:encodingStyle= n http://schemas.xmlsoap.org/soap/encoding/ ,, > 

<nmdrm:RtProtectContentReq> 

<Version/> 

<srvId/> 

<Source> 

<SourceContentfI>>230965</SourceContentID> 
<ContentName "Bond" /> 
<MimeType "application/jpg" /> 
<ContentDescription "nice jpg picture"/> 
<SourceContentLocation> 

<SourceLocation "http://mobile.nds.com/clearcontent7> 
<SourceDownloadProxy/> 
</SourceContentLocation> 
<ProtectContentLocation> 

<ProtLocation "http://mobile.nds.com/protectcontent"/> 
<ProtUploadProxy/> 
• " </ProtectContentLocation> 

</Source> 
<MobSubsId> 

<MobSubsIdType "mobile subscriberISDN'7> 
<MobSubsIdValue "97255664541"/> 
</MobSubsId> 
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<mobile subscribermodel "Nokia6220" /> 
<AssetRights> 
<Price> 

<priceValue>5.5</priceValue> 
</Price> 
<Permission> 
<play> 

<constraint> 

<count>3</count> 

</play> 
</Permission> 
<FLflag>0</FLflag> 
</AssetRights> 
</nmdrm:RtProtectContentReq> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

7.1 .2 RT Protect Content Response Message 

7.1 .2.1 Message definition 

<messagename= n ProtectContentReqResponse"> 

<part name= M DRMstatus" type="nmdrm:tDRMstatus7> 
<part name="CID" type="xsd:string7> 
</message> - - - - • 
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7.1.2.2 Types used 
nomolexTvoe tDRMstatus 


diagram 


— I — =ErrorCode |l 


(tDRMstatus Q-(-^-^H 


namespace 


http://www.ndsxomyNDSDRMS/vl.O/nmdrm.xsd 


children 


ErrorCode ErrorDescr 


used by 


elements 

ProtectContentReaResoonse/DRMstatus RoReaResoonse/DRMstatus 


DrmPermissionReaResDonse/DRMstatus tDRMstatus 




source 


<xsd:complexType name= ,, tDRMstatus"> 
<xsd:sequence> 
<xsd:element name-'ErrorCode" type="xsd:int"/> 

<xsd:element name^ErrorDescr" type^xsdrstring" nillable= n true" minOccurs^'O"^ 
</xsd:sequence> 
</xsd:complexType> 
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7.1.2.2.1 XML example 

<?xml version="1.0" encoding="UTF-8"?> 

<SOAP-ENV:Envelope xmlns:SOAP-ENV== ,, http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/ ,t 
xmlns:xsi="http://www. w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:nmdrm="http://www.nds.ro 

<SOAP-ENV:Body id=" J)" SOAP- 
ENV:encodingStyle= t1 http://schemas.xmlsoap.org/soap/encoding/"> 

<nmdrm:ProtectContentReqResponse> 

<DRMstatus> 

<ErrorCode>0</ErrorCode> 

</DRMstatus> 

<CID M Bondnnnn@mobile.nds.com" /> 
</nmdrm:ProtectContentReqResponse> 
</SOAP-ENV:Body> 



</SOAP-ENV:Envelope> 
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7.2 



RO Transaction 



7.2.1 



RO Request Message 



7.2.1.1 



Message definition 



<message name="RoReqRequest"> 

<part name= ,, Version" type="xsd:string , 7> 
<part name="srvld" type="xsd:string7> 
<part name="CID" type="xsd:string"/> 
<part name="MobSubsId" rype="nmdrm:tMobSubsId7> 
<part name="mobile subscribermodel n rype="xsd:string7> 
<part name=" AssetRights" type="nmdrm:tAssetRights7> 
</message> 



<?xml version= n 1.0" encoding="UTF-8"?> 

<SOAP-ENV:Envelope xmlns:SOAP-ENV= M http://schemas.xmlsoap.org/soap/envelope/ B 
xmlns:SOAP-ENC= ,, http://schemas.xmlsoap.o^g/soap/encoding/ ,, 
xmlns:xsi="http://www. w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema M 
xmlns:nmdrm="http://www.ndsxom/NDSDRMS/vl.O/nm 

<SOAP-ENV:Body id=" J)" SOAP- 
ENV:encodingStyle= H http://schemas.xmlsoap.org/soap/encoding/ ,, > 

<nmdrm:RoReq> 

<Version "1.0" /> 

<srvld "NDS0124"/> 

<CID "Bondnrmn@mobile.nds.com" /> 

<MobSubsId> 

<MobSubsIdType "mobile subscriberISDN7> 



7.2.1.2 



Types used 

The same types as for RT Protect Content request are used 



7.2.1.3 



XML example 



<MobSubsIdValue ,, 972556645417> 
</MobSubsId> 

<mobile subscribermodel M Nokia6220" /> 
<AssetRights> 
<Price> 

<priceValue>7.5</priceValue> 
</Price> 
<Permission> 
<play> 

<constraint> 

<count>5</count> 

</play> 
</Permission> 
<FLflag>0</FLflag> 
</AssetRlghts> 
</nmdrm:RoReq> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 
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7.2.2 RO Response Message 

7.2.2. 1 Message definition 

<message name="RoReqResponse n > 

<part name= n DRMstatus tt type="nmdrm:tDRMstatus7> 

<part name="RightsObject n type= n xsd:hexBinary"/> 
</message> 

7.2.2.2 Types used 

The same type as for RT Protect Content response is used. 

If Error Code parameter in the DRMstatus does not equal "OK", the RightsObject 
parameter in the response message is absent. 

7.2.2.3 XML example 

<?xml version="1.0" encoding="UTF-8 ,, ?> 

<SOAP-ENV:Envelopexmlns:SOAP-ENV= ^ http://schemas.xn^asoap.o^g/soap/envelope/ ,, 
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsi="http://www. w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://wrww.w3.org/2001/XMLSchema" 
xmIns:nmdrm= n http://www.ndsxom/NDSDRMS/vl.O/nmdrm.xsd"> 

<SOAP-ENV:Body id="J>" SOAP- 
ENV:encodingStyle= tt http://schemas.xmlsoap.org/soap/encoding/ ,t > 

<nmdrm:RoReqResponse> 

<DRMstatus> 

<ErrorCode>0</ErrorCode> 

<ErrorDescr/> 
</DRMstatus> 
<RightsObject> 

<ptr>0</ptr> 



<size>0</size> 
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</RightsObject> 
</nmdrm:RoReqResponse> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 



7.3 DRAA Permission Transaction 

7.3,1 DRM Permission Request Message 

7.3.1 .1 Message definition 

<messagename= ,, DrmPermissionReqRequest ,, > 

<part name=" Version" type="xsd:string7> 

<part name="srvld" type^'xsdistring"^ 

<part name= H rnobile subscribermodel" type="xsd:string7> 

<part name^MimeType" type="xsd:string7> 
</message> 

7.3.1.2 Types used 

The same types as in RT request message are used. 

7.3.1.3 XML example 

<?xml version= rt 1.0" encoding= ,, UTF-8"?> 

<SOAP-ENV:Envelope xmlns:SOAP-ENV= ,, http://schemas.xmlsoap.org/soap/envelope/ ,t 
xmlns:SOAP-ENC= n http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsi= M http://www.w3.org/2001/XMLSchema-ta 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:nmdrm= n http://www.ndsxom/NDSDRMS/vl.O/nmdrm.xsd M 

<SOAP-ENV:Body id="_0" SOAP- 
ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> 

<nmdrm:DrmPermissionReq> 
<Version> 1.0 </Version> 



<srvId>NDS2300 </srvId> 
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<mobile subscribermodel> Nokia6220 </mobile subscribermodel> 
<MimeType> application/jpg </MimeType> 
</nmdrm:DrmPermissionReq> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 



7,3.2 DRM Permission Response Message 

7.3.2.1 Message definition 

<message name="DrmPermissionReqResponse"> 

<part name= n DRMstatus" type= M nmdrm:tDRMstatus7> 

<part name= M mobile subscriberRights" type="nmdrrn:tmobiIe subscriberRights7> 
</message> 



t 
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7.3.2-2 Types used 

mmnlGxTvne t mobile subscriberRiqhts 


diagram 


,---! Permission Eft 
' w — J FLflag | 


namespace 


http://wv\w.ndsxon^NDSDRMS/vl.O/nmdrm.xsd 


children 


Permission FLflaq j 


used by 


elements 

DrmPermissionReaResoonse/mobile subscriberRiahts tmobile subscriberRiqhts 






source 


<xsd:complexType name="tmobile subscriberRights"> 
<xsd:sequence> 

<xsd:element name^'Permission" type="nmdrm:tPermission" nillable="true" minOccurs="07> 
<xsd:element name= u FLflag" type^'xsdrunsignedByte" niliable="true" minOccurs= H 07> 
</xsd:sequence> 
</xsd:comp!exType> 


The other types are the same as in the RT Response message. 



7.3.2.3 XML example 

<?xml version^l.O" encoding="UTF-8"?> 

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/ n 
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsi= n http://www. w3.org/2001/XMLSchema-instance" 
xmlm:xsd= M htrp://vvww.w3.org/2001/XMLSchema ,, 
xmlns:nmdrm="http://www.ndsxom/NDSDRMS/vl .0/nmdrm.xsd"> 

<SOAP-ENV:Body id="JT SOAP- 
ENV:encodingStyle=="http://schemas.xmlsoap.org/soap/encoding/"> 

<nmdrm:DRM-permission-Response> 

<DRM-status> 

<ErrorCode>0</ErrorCode> 

<ErrorDescr/> 

</DRM-status> 



<mobile subscriberRights> 
<Permission> 
<play> 

<constraint> 

<count>0</count> 
<datetime> 
<start/> 
<end/> 
</datetime> 
<interval>0</interval> 
</constraint> 
</play> 
<display> 

<constraint> 

<count>0</count> 
<datetime> 
<start/> 
<end/> 
</datetime> 
<interval>0</interval> 
</constraint> 
</display> 
<execute> 

<constraint> 

<count>0</count> 
<datetime> 
<start/> 
<end/> 
</datetime> 



<interval>0</interval> 
</constraint> 
</execute> 
<print> 

<constraint> 

<count>0</count> 
<datetime> 
<start/> 
<end/> 
</datetime> 
<interval>0</interval> 
</constraint> 
</print> 
</Permission> 
<FL-flag>0</FL-flag> 
</mobile subscriberRights> 
</nmdrm:DRM-permission-Response> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 
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Table 2 below describes the errors that the SP may receive in response to a request. 
Table 2: Error Handling 



Error code 


Error description 


0x0000 


Successful execution of the request 


0x0001 


Mobile Subscriber type is not defined in the DRM server 


0x0002 


Clear content file cannot be found 


0x0003 


Protected content location does not exist 


0x0004 


Download protocol is not supported 


0x0005 


Upload protocol is not supported 
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Appendix A: WSDL Schema ©f Protocol 

<?xml version= ,, 1.0 M encoding= M UTF-8 M ?> 

definitions name="NDSdrmPortal M xmlns= ,, http://schernas.xmlsoap.o^g/wsdl/ ,, 

xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/ tt 

xmlns:WSDL== n http://schemas.xmlsoap.org/wsdl/" 

targetNamespace= n http://www^^ 

" xmlns:tns= n http://www.ndsxon^^ 

xmlns:SOAP-ENV= ,, http://schemas.xmlsoap.org/soap/envelope/ n xmlns:SOAP- 

ENC= ,, http://schemas.xmlsoap.o^g/soap/encoding/ ,, 

xmlns:xsi="http://wv^.w3.org/2001/XMLSchema-instance" 

xmlns:xsd= n http://v^Avw.w3.org/2001/XMLSchema w 

xmlns:nmdrm= M http://www.ndsxom/NDSDRMS/vl.O/nmdrm.xsd"> 

<types> 

<schema targetNamespace= ,, http://www.nds.com/NDSDRMS/vl .O/nmdrm.xsd" 
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP- 
ENC^"http://schemas.xmlsoap.org/soap/encodingr 
xmlns:xsi=''http://ww^ 

xmlns:xsd^ M http://www.w3.org/2001/XMLScherna" 
xmlns:nmdrm= n http://www.ndsxommDSDRMS/vl.O/nmdrm.xsd" 
xmlns= ,, http://www.w3.org/2001/XMLSchema" elementFormDefault= ,, unqualified" 
attributeFormDefault="unqualified"> 

<elementname= !, tProtectContentLocation" 
type="nmdrm:tProtectContentLocation , 7> 

<complexType name= n tProtectContentLocation ,, > 
<sequence> 

<element name= H ProtLocation n type^xsdistring' 1 minOccurs=="r 

maxOccurs="l'7> 

<elementname= ,, ProtUploadProtocol" type^sdrstring" 
minOccurs= M 0 n maxOccurs="l" nillable="true7> 

<element name^ProtUploadProxy" type=°xsd:string" minOccurs="0" 
maxOccurs-'T nillable="true7> 
</sequence> 
</complexType> 

<elementname=:"tSourceContentLocation" 
type="nmdrm:tSourceContentLocationV> 
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<complexType name= ,, tSourceContentLocation"> 
<sequence> 

<elementname="SourceLocation" type== n xsd:string" minOccurs= M r 

maxOccurs="l7> 

<element name^'SourceDownloadProtocor type= ,, xsd:string M 
minOccurs^O" maxOccurs="l" nillable="true7> 

<element name^SourceDownloadProxy" type=="xsd:string" 
minOccurs="0" maxOccurs="l" nillable="true7> 

</sequence> 

</complexType> 

<element name^tSourceContent" type="nmdrm:tSourceContent7> 
<cornplexType name= tt tSourceContent"> 
<sequence> 

<element name^'SourceContentlD" type="xsd:long" minOccurs="l" 

maxOccurs=" 1 "/> 

<element name="ContentName" type=°xsd:string M minOccurs="l" 

maxOccurs-"l'7> 

<element name-"MimeType° type= M xsd:string" minOccurs= n r 

maxOccurs= M l7> 

<element name="EncodingType" type="xsd:string" minOccurs="0 n 
maxOccurs="l" nillable="true7> 

<element name=XontentProviderWeb M type="xsd:string" 
minOccurs="0" maxOccurs="l" nillable="true7> 

<element name="ContentVendor" type="xsd:string" minOccurs="0" 
maxOccurs="l M nillable="true7> 

<element name^XontentDescription" type="xsd:string M 
minOccurs="0" maxOccurs= ,, l" nillable= n true7> 

<element name= H SourceContentLocation" 
type= H nmdrm:tSourceContentLocation" minOccurs="0" maxOccurs="l" nillable= ,, true7> 

<element name="ProtectContentLocation w 
type= ,, nmd^m:tProtectContentLocation ,, minOccurs="0" maxOccurs="l M nillable="true7> 

</sequence> 
</complexType> 
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<element name^tMobSubsId" type="nmdrm:tMobSubsId7> 
<complexType name= n tMobSubsId u > 
<sequence> 

<element name= tt MobSubsIdType" type^xsdrstring" minOccurs= n l" 

maxOccurs="17> 

<element name="MobSubsIdValue" type= M xsd:string n minOccurs= n r 

max0ccurs= M l7> 

</sequence> 
</complexType> 

<element narne="tdatatime" type="nmdrm:tdatatime7> 
<complexType name="tdatatime"> 
<sequence> 

<element name= M start M type="xsd:dateTime" minOccurs^'O" 
maxOccurs="l n nillable= M true7> 

<e!ement name= M end n type="xsd:dateTime n minOccurs-'O" 
maxOccurs="l" nillable="true7> 

</sequence> 

</complexType> 

<element name="constraintType" type="nmdrm:constraintType7> 
<complexType name= M constraintType"> 
<sequence> 

<elementname="count n type="xsd:int" minOccurs="0" 
maxOccurs="l" nillable="true7> 

<eiement name="datetime M type="nmdrm:tdatatime" minOccurs="0 n 
maxOccurs="l" nillable="true7> _ ... - - - - ■ 

<element name= M interval" type="xsd:int" minOccurs="0" 
maxOccurs="l M nillable="true7> 

</sequence> 

</complexType> 

<elementname="tPermissionElement" type= n nmdrm:tPermissionElement7> 
<complexType name="tPermissionEIement ,, > 
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<sequence> 

<element name="constraint" type= ,, nmdrm:constraintType" 
minOccurs= M l M maxOccurs^T 1 ^ 
</sequence> 
</complexType> 

<element name= ,, tPermission n type= tt nmdrm:tPermission'7> 
<complexType name= ,, tPermission"> 
<sequence> 

<element name^play" type="nmdrm:tPermissionElement" 
minOccurs= M 0 M maxOccurs= ,, l n nillable="true7> 

<element name="display" type= M nmdrm:tPermissionElement n 
minOccurs= ,, 0" maxOccurs= u l n nillable= M true7> 

<element name="execute" type= M nmdrm:tPermissionElement" 
minOccurs="0" maxOccurs= n l" nillable="true7> 

<element name= rt print" type="nmdrm:tPermissionElement" 
minOccurs="0 n maxOccurs="l" nillable="true7> 

</sequence> 

</complexType> 

<element name^'tPi-ice" type="nmdrm:tPrice"/> 
<cornplexType name="tPrice"> 
<sequence> 

<element name="currency n type= ,, xsd:string" minOccurs= ,, 0 n 
maxOccurs="l" nillable="true7> 

<element name= M priceValue M type="xsd:float" minOccurs="l" 

maxOccurs= ,, 17> 

</sequence> 
</complexType> 

<element name="tAssetRights" type= n nmdrm:tAssetRights7> 
<complexType name="tAssetRights"> 
<sequence> 
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<element name= n Price" type^nmdrnr.tPrice" minOccurs= ,, l" 

maxOccurs='T7> 

<element name= t, Permission n type="nmdrm:tPermission" 
minOccurs= ,, 0" maxOccurs='T' nillable="true7> 

<element name= u FLflag M type="xsd:unsignedByte" minOccurs="0" 
maxOccurs="l f ' nillable="true7> 
</sequence> 
</complexType> 

<element name= M tmobile subscriberRights" type="nmdrm:tmobile 
subscriberRights"/> 

<complexType name="tmobile subscriberRights"> 
<sequence> 

<element name="Permission" type="nmdrm:tPermission" 
minOccurs="0" maxOccurs="l n nillable= n true7> 

<element naIne= ,, FLflag ,, type="xsd:unsignedByte" minOccurs= n 0" 
maxOccurs="l" nillable="true7> 
</sequence> 
</complexType> 

<element name="tDRMstatus M type="nmdrm:tDRMstatus7> 
<complexType name="tDRMstatus"> 
<sequence> 

<element name="ErrorCode n type= t, xsd:int" minOccurs= M l n 

maxOccurs= n 1 7> 

<element name= M ErrorDescr n type= M xsd:string" minOccurs="0" 
maxOccurs="r nillable="true7> 

</sequence> 

</complexType> 

<element name= n ProtectContentReqResponse" 
type= n nmdrm:ProtectContentReqResponse'7> 

<complexType name= M ProtectContentReqResponse"> 
<sequence> 
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<element name="DRMstatus" type= ,, nmdrm:tDRMstatus M 
minOccurs= ,, r maxOccurs='T7> 

<element name="CID" type-"xsd:string" minOccurs^'r 

maxOccurs=" 1 7> 

</sequence> 
</complexType> 

<element name= ,, RoReqResponse w type= ,, nmdrm:RoReqResponse7> 
<complexType name= t, RoReqResponse"> 
<sequence> 

<element name="DRMstatus" type= M nmdrm:tDRMstatus" 
minOccurs-"l" maxOccurs="l7> 

<element name="RightsObject" type="xsd:hexBinary tt minOccurs= n l" 

maxOccurs= M 1 7> 

</sequence> 
</complexType> 

<element name= ,, D^mPe^missionReqResponse ,, 
type= tt nmdrm:DrmPermissionReqResponse7> 

<complexType name= M DrmPermissionReqResponse"> 

<sequence> 

<element name="DRMstatus" type="nmdrm:tDRMstatus" 
minOccurs^l" maxOccurs='T7> 

<element nanie= M mobile subscriberRights" type= n nmdrm:tmobile 
subscriberRights" minOccurs="l" maxOccurs="l7> 

</sequence> 

</complexType> 

</schema> 

</types> 

<messagename="RtProtectContentReqRequest"> 
<part name="Version" type= ,, xsd:string7> 
<part name="srvld n type="xsd:string7> 
<part name="Source" type="nmdrm:tSourceContent7> 
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<part name^'MobSubsId" type="nmdrm:tMobSubsId7> 
<part name=s"mobile subscribermodel" type="xsd:string7> 
<part name= n AssetRights n type= M nmdrm:tAssetRights 7> 
</message> 

<message name="ProtectContentReqResponse M > 

<part name="DRMstatus" type-"nmdrm:tDRMstatus7> 

<part name="CID" type="xsd:string7> 
</message> 

<message name= ,, RoReqRequest"> 

<part name="Version M type^^Ksdistring"^ 

<part name="srvld" type="xsd:string7> 

<part name="CID" type="xsd:string'7> 

<part name="MobSubsId" type= ,r nmdrm:tMobSubsId"/> 

<part name="mobile subscribermodel" type="xsd:string7> 

<part name="AssetRights" type= n nmdrm:tAssetRights7> 
</message> 

<message name="RoReqResponse"> 

<part name="DRMstatus" type="nmdrm:tDRMstatus7> 

<part name="RightsObject" type="xsd:hexBinary7> 
</message> 

<message name="DrmPermissionReqRequest"> 

<part name="Version" type= r, xsd:string M /> 

<part name="srvld" type="xsd:string7> 

<part name="mobile subscribermoder type="xsd:string7> 

<part name="MimeType" type= M xsd:string7> 
</message> 

<message name="DrmPermissionReqResponse ,l > 

<part name="DRMstatus M type="nmdrm:tDRMstatus7> 

<part name^mobile subscriberRights" type="nmdrrn:tmobile subscriberRights7> 
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</message> 

<portType name= n NDSdrmPortalPortType"> 

<operation name= n RtProtectContentReq"> 

<documentation>Service definition of function 
nmdrm_RtProtectContentReq</documentation> 

<input message="tns:RtProtectContentReqRequest7> 

<output message-"tns:ProtectContentReqResponse M /> 

</operation> 

<operation name="RoReq"> 

<documentation>Service definition of function 
nmdrm_RoReq</documentation> 

<input message="tns:RoReqRequest7> 

<output message="tns:RoReqResponse"/> 

</operation> 

<operation name= t, DrmPermissionReq ,, > 

<documentation>Service definition of function 
nmdrm_DrmPermissionReq</documentation> 

<input message="tns:DrmPermissionReqRequest , 7> 

<output message= ,, tns:DrmPermissionReqResponse , 7> 

</operation> 

</portType> 

<binding name="NDSdrmPortalBinding n type= tt tns:NDSdrmPortalPortType ,, > 

<SOAP:binding style="rpc M transport= n http://schemas.xmlsoap.org/soap/http7> 
^operation name="RtProtectContentReq"> 

<SOAP:operation soapAction="7> 

<input> 

<SOAP:body use= M encoded" 
namespace= ,, http://www.nds.con^/NDSDRMS/vl.O/nmd^nl.xsd ,, 
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/7> 

</input> 



<output> 

<SOAP:body use="encoded" 
namespace=' , http://www.ndsxom/NDSDRMS/vl.O/nmd^In.xsd ,, 
encodingStyle= M http://schemas.xmlsoap.org/soap/encoding/7> 

</output> 

</operation> 

<operation name="RoReq"> 

<SOAP:operation soapAction="7> 

<input> 

<SOAP:body use= ,, encoded ,, 
namespace="http://www.ndsxom/NDSDRMS/vl.O/nmdrm.xsd" 
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/7> 

</input> 

<output> 

<SOAP:body use="encoded" 
namespace="http://www.ndsxoIXl/NDSDRMS/vl.O/nmdrm.xsd ,, 
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/7> 

</output> 

</operation> 

<operation name= M DrniPermissionReq M > 

<SOAP:operation soapAction="7> 

<input> 

<SOAP:body use= n encoded" 
namespace="http://www.ndsxom/NDSDRMS/vl.O/nmdrm.xsd" 
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/7> 

~ </ihput> 

<output> 

<SOAP:body use="encoded" 
namespace= M http://www.ndsxom/NDSDRMS/vl.O/nmdrm.xs 
encodingStyle="http://schernas.xmlsoap.org/soap/encoding/7> 

</output> 

</operation> 
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</binding> 

<service name= n NDSdrrnPortar> 

<documentation>gSOAP 2.3 rev 2 generated service definition</documentation> 

<port name="NDSdrmPortal n binding="tns:NDSdrmPortalBinding"> 

<SOAP:address 
location="http://www.ndsxorn/NDSDRMS/NDSdrniPortal7> 

</port> 

</service> 

</definitions> 
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Technical Glossary: Acronyms and Abbreviations 



Knowledge of the acronyms and abbreviations defined in this technical glossary may 
be helpful to understanding the information in the present document. 



Acronym/Abbreviation 


Definition 


DCF 


DRM Content Format 


DRM 


Digital Rights Management 


DS1G 


Digital Signature 


HS 


Handset 


ICD 


Interface Component Document 


MIME 


Multipurpose Internet Mail Extension 


MGMS 


Management Station 


MS 


Mobile Subscriber 


M5ISDM 


Mobile Station Integrated Services Digital Network 


OMA 


Open Mobile Alliance organization 


RO 


Rights Object 


SP 


Service Provider 


WBXML 


WAP (Wireless Application Protocol) Binary Extended 




Markup Language 


WSDL 


Web Service Definition Language 


XID 


Exchange Identifier 



